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Relationship to Mathematical Optimisation, 
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Abstract Requirements Engineering (RE) focuses on eliciting, modelling, and an¬ 
alyzing the requirements and environment of a system-to-be in order to design its 
specification. The design of the specification, usually called the Requirements Prob¬ 
lem (RP), is a complex problem solving task, as it involves, for each new system- 
to-be, the discovery and exploration of, and decision making in, new and ill-defined 
problem and solution spaces. The default RP in RE is to design a specification of the 
system-to-be which (i) is consistent with given requirements and conditions of its 
environment, and (ii) together with environment conditions satisfies requirements. 
This paper (i) shows that the Requirements Problem for Adaptive System (RPAS) is 
different from, and is not a subclass of the default RP, (ii) gives a formal dehnition 
of the RPAS, and (iii) discusses implications for future research. 


1 Introduction 

1.1 Domain: Requirements Engineering 

Requirements Engineering (RE) focuses on eliciting, modelling, and analysing 
the requirements and environment of a system-to-be in order to design its specifica¬ 
tion. 

It is on the basis of its specification that the system is built, updated, changed, its 
new releases planned, made, announced, rolled out. Specifications can take different 
forms, ranging from minimalistic to-do lists that hint at expectations and subsume 
implicit engineering solutions, to elaborately structured documentation on contracts 
with employees and suppliers, responsibilities of positions in the value chain, guide- 
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lines for employee coordination and collaboration, as well as formal software spec¬ 
ifications made for use with a model checker. 

The design of the specification, usually called the Requirements Problem (RP), 
is a complex problem solving task, as it involves, for each new system-to-be, the 
discovery and exploration of, and decision making in, new and ill-defined problem 
and solution spaces. 

Difficulties involved in solving an RP instance are illustrated by the variety of 
topics studied in RE research, such as requirements elicitation ||23l|2i[l6l, catego¬ 
rization oiiiMiisa, vagueness and ambiguity Il45ll4^[^ . prioritization 13^ 121 12^ . 
negotiation ll42l [3ll^. responsibility allocation |[l4l[TT]|2Tl, cost estimation ID [71 
|53]| . conflicts and inconsistency ll46l l26l l57l . comparison Il45ll43ll44l . satisfaction 
evaluation ||6l|45]|4T], operationalization ETlITTlfTTl . traceability ll24ll50lfT3l . and 
change ifTH l5^ [TOl . 

RE issues are present when designing new and changing existing systems; they 
are there whatever the system class and domain, and regardless of the extent to 
which people are involved in the system: from autonomic Internet-scale clouds, to 
traditional desktop applications, industrial expert systems, and embedded software, 
all enabling anything from massive mobile apps ecosystems, global supply chains, 
medical processes, business processes, mobile gaming, and so on. Moreover, RE 
issues are present regardless of how the software in the system is designed and 
made, from a military waterfall to a startup’s own agile dialect, and from organisa¬ 
tions where developers talk directly to customers, to those where product designers, 
salespeople, or others mediate between requirements and code. 


1.2 Context: Default Requirements Problem 

The de facto default view in RE, is that the specification is produced incrementally, 
starting from a limited set of incomplete, inconsistent, and imprecise information 
about the requirements and the system’s operating environment, and that each de¬ 
sign step reduces incompleteness, removes inconsistencies, and improves precision, 
towards the specification of the system ||5] [Ml [25l 061120] |6T] |56l [H] [52] [^ [TtII . 

This important and general conceptualisation of the aim in RE is most clearly 
formulated in Zave & Jackson’s seminal paper, “Eour dark comers of requirements 
engineering” Ell. Their view, denoted ZJ hereafter, is echoed in some of the most 
influential research in the held, which both preceded and followed the said paper, 
including, for example, contributions from Boehm et al. 0111, van Lamsweerde et 
al. d 05] [52l |58l EH US, Mylopoulos et al. E] [25] QIl, Robinson et al. li52ll . 
Nuseibeh et al. B6ll30l . to name some. 

According to the ZJ view, in any concrete systems engineering project, RE is 
successfully completed when the following conditions are satisfied ED: 

1. “There is a set R of requirements. Each member of R has been validated (checked infor¬ 
mally) as acceptable to the customer, and R as a whole has been validated as expressing 
all the customer’s desires with respect to the software development project. 
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2. There is a set K of statements of domain knowledge. Each member of K has been vali¬ 
dated (checked informally) as true of the environment. 

3. There is a set SS of specifications. The members of S do not constrain the environment; 
they are not stated in terms of any unshared actions or state components; and they do 
not refer to the future. 

4. A proof shows that K,Sh R. This proof ensures that an implementation of S will satisfy 
the requirements. 

5. There is a proof that 5 and K are consistent. This ensures that the specification is inter¬ 
nally consistent and consistent with the environment. Note that the two proofs together 
imply that 5, K, and R are consistent with each other.” 

If the satisfaction of these conditions marks the end of RE in any systems engi¬ 
neering project, then we can give a compact formulation of the default problem that 
RE should solve, which we call the Default Requirements Problem hereafter: 

Definition 1. Default Requirements Problem (DRP): Given a set R of require¬ 
ments, and a set K of domain knowledge, find a specification S, such that S satisfies 
the following conditions; 

1. There is a proof of R from K and S, written /T, 5 h R, 

2. K and S are consistent, written K,S\/ 


1.3 Issue: What if the System is an Adaptive System? 

A system is an Adaptive System (AS) if it can detect differences between its design¬ 
time and run-time requirements and environment conditions, uses feedback mech¬ 
anisms to analyse these changes and decide, with or without human input, how to 
adjust its behaviour as a result. 

There is nothing in the DRP which makes it specific to a system class. This would 
suggest that the RP for AS is a subclass of DRP, in the sense that it is the DRP, with 
some additional properties that make it specific to the Adaptive Systems class. 

It is important to know whether RPAS is a subclass of the DRP. According 
to Zave & Jackson, DRP “establish[es] minimum standards for what information 
should be represented in a requirements language” ED. 

But this is not only important because of the interest in the design of languages 
for the representation of requirements, domain knowledge, and specifications of 
ASs. 

More generally, if it is the valid conclusion, then there are existing RE tools 
(representation languages, methods, algorithms, etc.) that should be used in RE for 
AS, and the open question is how to specialise them to AS. 

If it is not the valid conclusion, then the issue is to know which of the existing 
research is relevant for solving RPAS, both in RE and elsewhere, and what new 
research is needed. In both cases, discussing the validity of the conclusion above 
should provide relevant input for future research on RE for AS, and relate it to the 
default view of RE. 
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1.4 Contributions: Requirements Problem for Adaptive Systems 
and its Relationship to the Default Requirements Problem 


This paper has three parts; 

1. Part one runs from Sectionj^to Section]^ It argues that the Requirements Prob¬ 
lem for Adaptive System (RPAS) is different from the DRP, and that it is not a 
subclass of the DRP. This is argued in the following steps: 

a. The starting point, developed in Section]^ is the observation that DRP is the 
minimal RP, in the sense that if something is removed from it, there is no 
meaningful problem left to solve. 

b. Minimality suggests that there may be similarity between the DRP and every 
other RP, including the RPAS. The second step of the argument, developed 
in Section]^ is the observation that the DRP is not the superclass of all RPs, 
despite its minimality. This is argued by showing that, if we want to compare 
specifications when solving an RP, and we do it in order to choose the one that 
is somehow the optimal one, then that RP is not a subclass of the DRP. 

c. The third step of the argument, in Section]^ shows that to want the optimal 
specification as a solution to an RP, is not a new idea in RE. It has been studied 
in research on non-functional requirements. We argue that, once there are non¬ 
functional requirements in an RP, then this RP is not a subclass of the DRP. 

d. The fourth step of the argument, in Section shows that optimality and 
non-functional requirements are central to Adaptive Systems engineering, and 
therefore, that RPAS is not a subclass of the DRP. 


2. Part two proposes a general definition of the RPAS. This is done in four steps: 

a. Section|^introduces new concepts, of problem and solution spaces, of criteria 
and parameters, and so on, for defining RPs in general. The new concepts are 
motivated by the discussion in part one of the paper. 

b. Sectionj^connects the discussion of optimality to the new concepts introduced 
in Section|6] 

c. Section introduces a new class of RPs, called Requirements Optimisation 
Problems, used to define the RPAS. 

d. Section^defines the RPAS. 


3. Part three, in Sections 10 12 relates the RPAS to mathematical optimisation 


in general, to decision analysis in management science, and to expected utility 
theory in economics. 


2 The Default Requirements Problem is a Minimal RP 

DRP is a minimal RP, in the sense that if any of its parts is removed, the rest is not 
an interesting problem for RE, or no problem at all. 
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To see this, consider the following rewriting of the DRR The only difference 
from Definition is that there are now labels on parts of the problem statement. 
Labels are used as follows: to label the statement “it is raining” with the label X, we 
write [it is raining: X]. 

Definition 2. Default Requirements Problem (DRP): Given [a set R of require¬ 
ments: R], and [a set K of domain knowledge: K], find [a specification S: S], such 
that [5 satisfies the following conditions: DR]: 

1. [There is a proof of R from K and S, written K,S\- R: Satisfaction Condition], 

2. \K and S are consistent, written 1/ _L: Consistency Condition]. 

There are labels on six parts of the problem statement. R refers to the set of 
requirements, K to the set of domain knowledge, and S to the specification. DR 
refers to the decision rule, that is, a rule stating what the thing to find, namely S, 
needs to satisfy, in order for it to be a solution to the problem. The Satisfaction 
Condition refers to the condition that there should be a proof of R from K and S, and 
the Consistency Condition to the consistency of K and S. 

It should be fairly straightforward to notice that removing any one of the labelled 
parts leaves no problem at all, or no problem of interest to RE: 

• If R is removed, then Satisfaction Condition has to go too, and this remains: 

Given [a set K of domain knowledge: K], find [a specification S: S], such that [5 satisfies 
the following condition: DR]: [K and S are consistent, written K,S\/ T.: Consistency 
Condition] 

Any S which is consistent with is a solution to this problem, making this an 
uninteresting problem for RE, given that the any solution to this problem is de¬ 
signed independently from requirements. 

• If K is removed, then this remains: 

Given [a set R of requirements: R], find [a specification 5: S], such that [5 satisfies the 
following conditions: DR]: 

1. [There is a proof of R from S, written 5 h R: Satisfaction Condition] 

2. [R and S are consistent, written R,S\/ -L.: Consistency Condition] 

Note that the Consistency Condition is changed above; another option is to re¬ 
move the Consistency Condition altogether, rather than rewrite it so that R and S 
have to be consistent. In both cases, what remains is not a relevant problem, since 
it says that any specification, including those defined independently from the en¬ 
vironment conditions, will be a solution, as long as it satisfies the two conditions 
above. 

• If the Consistency Condition is removed, then every inconsistent specification 
becomes a solution. This happens if h is understood as the syntactic consequence 
relation of classical logic. This relation, then, satisfies satisfies the exfalso quod 
libet proof pattern, which is that anything follows from an inconsistent set of 
formulas. Here, it means that if 5 h _L, then K,S\- R, whatever the content of R 
and K. 

• If the Satisfaction Condition is removed, the result is the same as removing R. 
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3 The Default Requirements Problem is not the Unique RP 


The conclusion of this section will be that the DRP is not the unique RP, and there¬ 
fore, that DRP is not the superclass of all RPs. 

Section [TT] explains what it means for an RP to be unique, and gives the main 
reason why it matters to know whether the DRP is unique. Section 3.2 lists proper¬ 


ties that an RP can inherit from the DRP. Section 3.3 gives three RPs different from 
the DRP, and discusses what properties they inherit from the DRP, and in particular 
if they inherit all its properties. Section [T4| defines the optimality property, which 
is implicit in the DRP. Section [33] argues that there are RPs which have a different 
optimality property than the DRP, and therefore, are not subclasses of the DRP. 


3.1 Uniqueness Matters because of Inheritance 


Uniqueness matters, because if DRP is the unique RP, then all RPs have at least the 
same properties as DRP. And if this is the case, then if we know how to solve DRP, 
this should help design ways to solve RPs in any other RP class. 

Now, it may seem obvious that RE involves so many different problems, such as, 
for example, those related elicitation and negotiation, which look nothing like the 
DRP. And so, the conclusion from that already is that there is no unique RP. 

However, any elicitation problem, negotiation problem, and so on, which tends 
to arise when doing RE, is really a problem that arises only because a system design 
needs to be made or changed. If elicitation is done without the aim of making or 
changing a system design, documented as a specification, then that problem is not 
an RE problem at all. 

The unique RP, if there is one, would be the unique root of the taxonomy of RPs. 
This would be the taxonomy of problems of designing systems. Designing the system 
is the central problem for RE, one that gives the motivation for solving many other 
problems that arise when doing RE. These other problems, however difficult they 
may be, are the side effects that we have to deal with, because we are interested in 
designing systems. 


3.2 What Can an RP Inherit from the DRP? 

To see if an RP is a subclass of another, it is necessary to define what one can inherit 
from the other. If an RP X is a subclass of an RP Y, then X will inherit all the 
properties of Y. 

Definition 3. Default Requirements Problem properties: The properties that an 
RP can inherit from DRP are motivated by the parts identified in Definition]^ These 
properties are as follows: 
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1. R Property: RP recognises that there is a category of information which describe 
conditions that are desired. 

2. K Property: RP recognises that there is a category of information which describe 
conditions that hold independently from the system-to-be, and that the system- 
to-be has to live with. 

3. S Property: RP recognises that there is a category of information which describe 
the system-to-be. 

4. KSR Property: RP recognises that there are no categories of information other 
than those referred to by R, K, and S properties, which are relevant when solv¬ 
ing DRP. In other words, all other kinds of information that may be useful are 
specialisations of those identified by the said properties. 

5. Satisfaction Property: RP requires any solution to it to be such that there is proof 
that, if conditions described in K hold, and the system is implemented according 
to S, then conditions in R will be satisfied. 

6. Consistency Property: RP requires that any solution to it be such that the con¬ 
ditions described in the K and S properties are not logically inconsistent. 

7. Decision Ruie Property: A description of a system-to-be is a solution to the RP 
if it satisfies the Consistency Property and the Satisfaction Property. 


3.3 A Case of Complicated Inheritance 

To illustrate inheritance between RPs, this section discusses three RPs. 


3.3.1 RPl 

The following is the first RP, named RPl. 

RPl: Given [a set G of goals: Gl, and [a set K of domain knowledge: K], find [a specifi¬ 
cation 5: SI, such that [S satisfies the following conditions: DR]: 

1 . [There is a proof of goals in G from K and S, written K,S^ G‘. Satisfaction Condition], 

2. \K and S are consistent, written K,S\/ L-. Consistency Condition]. 

RPl differs from DRP in that it has no mention of requirements R, but says that 
goals in G should be satisfied. However, the set of goals G has the exact same role 
in RPl as requirements R has in DRP: both are used to capture information about 
desired conditions that the system-to-be should satisfy. RPl is therefore a subclass 
of DRP, because it inherits all properties, including the R and KSR properties. 


3.3.2 RP2 


The second RP is as follows. 
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RP2: Given [a set R of requirements, partitioned onto mandatory requirements and 

non-mandatory requirements R^^: R], and [a set K of domain knowledge: K], find [a 

specification 5: S], such that [5 satisfies the following conditions: DR]: 

1. [There is a proof of mandatory requirements in R^ C R from K and S, written K,Sh R*^: 

Satisfaction Condition], 

2. \K and S are consistent, written ^,5 ^ -L: Consistency Condition], 

The difference is between RP2 and DRP is that the set of requirements R is 
partitioned onto mandatory and non-mandatory requirements in RP2. A solution 
therefore does not need to satisfy all requirements in R, but a subset thereof. RP2 is 
equivalent to DRP when all requirements in R are mandatory. 

There are two ways of looking at inheritance between RP2 and DRP. One is to say 
that RP2 specialises the concept of requirement onto mandatory and non-mandatory 
requirement, and rewrites the Satisfaction Condition accordingly. The other is that 
RP2 is obtained by taking that R in DRP includes only mandatory requirements, 
and saying that there are other, non-mandatory requirements which remain outside 
DRP; in this second case, RP2 is the same problem as DRP, with the added set 
of non-mandatory requirements, which remain unrelated to the specification, and 
thereby not a factor that influences the design of the specification. 

In both cases, RP2 looks like a subclass of DRP, because non-mandatory require¬ 
ments play no role in the problem or the solution. RP2 thereby inherits all properties 
of DRP, and adds two properties: one is that any requirement is either mandatory or 
non-mandatory, and the other that a solution should satisfy all mandatory require¬ 
ments. 

Returning to the more general discussion, recall that in Section]^ it was argued 
that the DRP is minimal by looking at what remains after some part of it is removed. 

There is a clear correspondence between parts of the DRP in Deflnition|^and the 
properties in Deflnition[^ 

Due to that correspondence, it follows that if a part is removed, then what re¬ 
mains will fail to satisfy all the DRP properties. Therefore, the set of properties in 
DeflnitionOis minimal. 


3.3.3 RP3 

It was straightforward to determine what RPl and RP2 inherited from DRP. RP3 is 
a more complicated case. 

RP3: Given [a set R of requirements, partitioned onto mandatory requirements R^ and 
non-mandatory requirements R^^\ R] and [a set K of domain knowledge: K] , find [a 
specification 5: S], such that [5 satisfies the following conditions: DR]: 

1. [There is a proof of mandatory requirements in R^ C R from K and S, written AT, 5 h R ^: 

Satisfaction Condition], 

2. \K and S are consistent, written K.Sf L: Consistency Condition], 
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3. [There is no other specification S' which satisfies both the Satisfaction Condition and 
the Consistency Condition, and in addition satisfies more of the non-mandatory require¬ 
ments in than does S: Optimality Condition.] 

RP3 partitions requirements onto mandatory and non-mandatory. In RP2, the 
non-mandatory requirements had no influence on which specification will be the 
solution. In RP3, the non-mandatory requirements appear in the Optimality Condi¬ 
tion, that a specification has to satisfy in order to be the solution. 

This suggests that the solution concept in RP3 is a subclass of the solution con¬ 
cept in RP2. In RP2, a solution is any specification which satisfies the Satisfaction 
Condition and the Consistency Condition, while in RP3, the specification also has to 
satisfy the Optimality Condition. In other words, the extension of the RP3 solution 
concept is a subset of the RP2 solution concept. 


3.4 Optimality in the Default Requirements Problem 

The Optimality Condition in RP3 is significantly different from the Satisfaction 
Condition and the Consistency Condition, because the Satisfaction Condition and 
Consistency Condition are verified on a single specification, and it does not matter 
what other specifications there may be, while to verify if the Optimality Condition is 
satisfied, it is necessary to compare two or more specifications. 

It is therefore not possible to check if the Optimality Condition in RP3 is satisfied, 
when looking at one specification independently from others. 

If we found a single specification S, which satisfies the Satisfaction Condition 
and the Consistency Condition, then in absence of at least one other specification 
S' with which to compare S in terms of how many non-mandatory requirements 
they satisfy, there will be no justification to the claim that S satisfies the Optimality 
Condition. 

The DRP has its own notion of optimality, which is implicit in the Decision 
Ruie Property. 

To see it, suppose that there are three specifications 5i, S 2 , and ^ 3 , and that they 
all satisfy the Satisfaction Condition and the Consistency Condition for the same set 
of requirements R and the same domain knowledge K. Which of the three specifica¬ 
tions is the optimal one? 

The Decision Ruie Property says that a specification is the solution if it satis¬ 
fies the Satisfaction Condition and the Consistency Condition. As there is no other 
property that a specification needs to satisfy to be a solution, the only remaining 
conclusion is that any specification that satisfies the Satisfaction Condition and the 
Consistency Condition is optimal. 

To make explicit the notion of optimality in DRP, we add the following property 
to the DRP. 
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Definition 4. Optimality Property for the DRP: RP recognizes that if there are 
more than one description of the system-to-be, all of which satisfy the Satisfaction 
and Consistency Properties, then they are all equally desirable. 

This leads to the following revision of the properties that an RP can inherit from 
the DRP. 

Definition 5. Default Requirements Problem properties (revised): The proper¬ 
ties that an RP can inherit from the DRP are R, K, S, KSR, Satisfaction, and Con¬ 
sistency Properties from Definition]^ the Optimaiity Property from Definition]^ 
and the following property: 

• Decision Ruie Property: A description of a system-to-be is a solution to the RP 
if it satisfies the Consistency, Satisfaction, and Optimaiity Properties. 


3.5 How are Optimality and Uniqueness related? 

Optimality is important, because it is related to uniqueness in the following way: 

In order to establish if a specification is the optimal specification and therefore 
the solution to the RP, it is necessary to compare specifications; any comparison of 
specifications requires having in the RP the information about comparison criteria; 
such information is not part of requirements, domain knowledge, or of the specifi¬ 
cation in the DRP, which violates the KSR Property, and therefore, the DRP is not 
unique. 

To understand the above, suppose that in a concrete systems engineering project, 
we have the set R of requirements and K of domain knowledge. In RPl, we simply 
called every requirement a goal, so that both the RPl and the DRP have the same 
set of specifications, each of which can be a solution. 

It makes sense therefore to conclude that the RPl is a subclass of DRP, or that 
they are equivalent RPs, because for any given R and K, solving the RPl or the 
DRP will involve choosing one solution from the same set of potential solutions. 
Moreover, in absence of comparison criteria in either the DRP and RPl, we can 
choose any of the specifications as the solution. 

For simplicity, the set of all specifications that we can choose one solution from, 
when solving an RP, will be called the Solution Space of that RP. 

So the Solution Space is the same for RPl and DRP, for the same given sets of 
requirements and domain knowledge. 

Despite the similarities between RP2 and DRP, their Solution Spaces are differ¬ 
ent. In DRP, all requirements in a given set R of requirements must be satisfied. In 
RP2, that same set is partitioned onto mandatory R^ and non-mandatory R^^ re¬ 
quirements. It follows that the Solution Space of RP2 for given requirements R and 
domain knowledge K is the same as the Solution Space of DRP defined over those 
same requirements and domain knowledge only if R^ = R and R^^ — 0. Instead, 
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if any member of R is in then it is by definition of RP2 not in R^, and conse¬ 
quently, the Solution Space ofRP2 will not include the same specifications that the 
Solution Space of the corresponding DRP would. 

If an RP X is a subclass of another RP Y, then for the same given requirements 
and domain knowledge, every solution to X should also be a solution to Y. This is 
not the case in RP2. 

The RP3 is not a subclass of the DRP for the same reason; as soon as some 
members of R are in R^^, the Solution Spaces of RP3 and DRP will differ, as some 
specifications that can be solutions to the RP3 will fail to satisfy the non-mandatory 
requirements in R^^ and therefore cannot be in the Solution Space of the DRP 
defined over the same set of requirements R and the same domain knowledge K. 

Now, it is fair to observe that RP2 is an odd RP, because there seems to be no role 
for non-mandatory requirements in it. But this same observation cannot be made 
for RP3, where non-mandatory requirements serve to define the criterion for the 
comparison of specifications in the Solution Space; that criterion is given in the 
Optimality Condition of RP3. 

It is interesting to note that the conclusion we got here is counter-intuitive. To 
make RP3, we did three operations: (i) we specialised requirements onto mandatory 
and non-mandatory ones, (ii) revised the Satisfaction Condition, so that it reflects 
the idea that only mandatory requirements must be satisfied, and (iii) added the 
Optimality Condition. The three operations are non-controversial; we could not do 
(i) without also doing (ii), and doing (i) also made no sense without doing (iii). 

The result is counter-intuitive, because the operation (i) looks simply like the 
specialisation of a concept that is already there in the DRP, and (iii) as just us asking 
that every solution satisfies an additional property, and so a specialisation of the 
DRP solution concept. If we look at each of these operations in isolation, they look 
like we are merely adding detail to what the DRP already had. 

But together, the three operations resulted in a different problem to solve, because 
by solving RP3, we can get solutions to RP3 which are not solutions to DRP. Hence, 
RP3 cannot be a specialisation of the DRP. 


4 Non-functional Requirements as Comparison Criteria 

Non-functional requirements are an important source of comparison criteria. This 
section will argue that, if there are non-functional requirements in an RP, and we 
extract from them the criteria for the comparison of specifications, and we want 
to find the optimal specification according to those criteria, then the RP is not a 
subclass of the DRP. 

Suppose that stakeholders give us non-functional requirements, also called qual¬ 
ity requirements Eiiia. For an ambulance system, an example can be the require¬ 
ment that “ambulances should quickly arrive at incident locations”; denote this re¬ 
quirement rl. There is no universal criterion or industrial standard for just how 
much time amounts to “fast” in this requirement. 
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If we wanted to keep solving the DRP in the presence of non-functional require¬ 
ments, we could do this by replacing each non-functional requirement by a variant, 
the satisfaction of which is binary. For example, “on average, ambulances should 
arrive to incident locations within 10 minutes”; denote this r2. And we could then 
have such K and 5, that we can prove rl from them. All looks as if we are still 
solving the DRP. 

But this transformation of rl misses the point. While rl looks like a require¬ 
ment, its role in the RP is completely different than that of r2. 

The non-functional requirement rl serves as a criterion for the comparison of 
alternative specifications, because it states a preference relation: by saying that 
ambulances should quickly arrive, it states that, when given two systems, one in 
which ambulances arrive slower, that one will - over this criterion only - be strictly 
less desirable than the system in which ambulances arrive faster. This is not at all 
the same as saying that ambulances should arrive within 10 min, since in that case, 
any system which satisfies this is good enough, while in the former case, only that 
system which achieves - among all those cosnidered - the shortest time for the 
ambulance to arrive, is good enough (again, if this criterion alone is considered, 
because when there are many criteria, perhaps some other criterion will have more 
importance). 

Different specifications, each associated to a different design of the system-to- 
be, may result in different average time for an ambulance to arrive at the incident 
location. Some specifications will result in systems that will be faster, others slower. 

There is, therefore no sense in placing r2 in R, because how fast one specifica¬ 
tion is (or, to be precise, how fast we expect the resulting system to be), is relative 
between specifications. We cannot prove it from K, and S for one specification, be¬ 
cause we have to take into account other, alternative, specifications. 

Suppose that we do not accept the arguments above, and we want to do something 
to non-functional requirements in order to still keep solving the DRP. Here are some 
possible attempts to repair the situation: 

1. We could rewrite rl as r3, with r3 denoting the statement “specification S is 
the specification with the lowest time for an ambulance, on average, to arrive 
at an incident location”, and put r3 in R. But notice that r3 is a rather odd 
requirement, since it is about the relationship between different specifications. 
This is also a practical problem, as it is not clear how we could prove r 3 from K 
and S, unless K and/or S also are about, or somehow mention other specifications. 

2. We could say that r 1 is not a member of R, but stays outside K, S, and R, and that, 
to enable the comparison of specifications, we should add a variable, denote it 
q, for “average time to arrive at incident location”, and that we should simulate, 
or estimate otherwise the value of q for each specification. If the various non¬ 
functional requirements result in a set Q of such variables, we could revise DRP 
by requesting that, for each specification Si, this holds: 


K,Si^R,Qi 


(1) 
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where Qi is the set of value assignments to all variables in Q, produced by the 
specification 5,. We could then compare different specifications by the values 
they assign to variables, whereby we chose the variables to quantify level of 
satisfaction of non-functional requirements; for example, we could assume that 
there is a scale for time for rl, where values indicate the average time to arrive 
at an incident location. 

3. We can replace syntactic consequence h with another relation; if we denote the 
new relation with |~, we would need to define it in such a way that we have: 


K,Siy^R ( 2 ) 

if and only if (i) R is provable from K and Si, and (ii) there is no other spec¬ 
ification Sj that better satisfies the non-functional requirements. Defining “bet¬ 
ter” requires us to define a way to aggregate, for each specification, the levels at 
which it satisfies all non-functional requirements, and then compare that aggre¬ 
gate score with those of all other specifications. The best specification would be 
the one with the highest score. 

In each of the three approaches above, we made significant changes to DRP, in or¬ 
der to accommodate non-functional requirements. That is, we made new problems, 
different from the DRP: 

• In the first approach, we revised the non-functional requirement rl as r3 and 
placed r3 in R. However, r3 is about other specifications, yet DRP is about 
conditions that a single specification should satisfy, independently from others. 

• In the second approach, we had to add Qi, the assignment of values to measures 
of non-functional requirements. It is not a problem to have Qi as a subset of R. 
However, if we want to choose the specification Si which gives the most desirable 
Qi, then we are not solving the DRP, because the part DR in DRP does not 
say that we should choose the most desirable specification which satisfies the 
Satisfaction Condition and the Consistency Condition. It actually says nothing 
about how desirable the specification ought to be, relative to other specifications 
which also satisfy these conditions. 

• Finally, in the third approach, we replaced the provability condition with a rela¬ 
tion |~, which has to take into account the level to which non-functional require¬ 
ments are satisfied in all considered specifications. 

To summarise, while DRP is minimal, it is not unique. As soon as there is in¬ 
formation about criteria for the comparison of specifications in the Solution Space 
and we are interested in choosing the specification which best satisfies these non¬ 
functional requirements (whatever “best” may mean precisely in a specific project), 
then we are solving a different problem than DRP. 
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5 Optimality and Comparison are Central to Adaptive Systems 

At this point, the important conclusion is that the DRP is not the superclass of RPs, 
in which we are interested in finding the optimal specification, and we have infor¬ 
mation that lets us compare specihcations. 

The claim in this section is that RPAS is not a subclass of the DRP, because opti¬ 
mality and comparison play a central role in it: namely, adaptation amounts to the 
switching between alternative ways of satisfying requirements, and therefore, each 
time the system needs to adapt, it needs to compare alternative ways of adapting, 
and choose the optimal one, among those that are available. 

To further clarify this discussion, the rest of this section uses a trivial and hypo¬ 
thetical example, but sufficient to support these claims. 


5.1 Adaptation as Switching 

In this example, by qualitative requirement, we mean a requirement for which we 
say that it is either satished or not, not satished to some extent. By quantitative 
variable requirement, we mean a requirement that assigns a desirable value or range 
of values to a variable, which is not binary. 

We have only two qualitative requirements r A and rB to satisfy. We know that we 
can satisfy r A by implementing one of hve different functionalities, denoted r AF1 
to rAF5, and rB by implementing another five different functionalities, denoted 
rBFl to rBF5. For simplicity, let all ten functionalities be different and not related 
in terms of rehnement or parthood, that is, they are neither more detailed variants of 
one another, nor parts of one another. 

With two qualitative requirements and 5 functionalities satisfying each, there are 
25 combinations of the 10 functionalities. But, some functionalities are not compat¬ 
ible. This means that we cannot make a system which includes them both. Some 
combinations of functionalities therefore do not give a specihcation which satishes 
both rA and rB. 

The part of the example introduced so far can be drawn as in Figure [T] There, 
hlled circles are specihcations, that is, combinations of functionalities that satisfy 
both rA and rB. Empty circles are incompatible combinations of functionalities, 
and since we cannot make a system that has those functionalities, these empty circles 
are not specihcations. 

If our problem was to hnd one combination where functionalities are compatible, 
and which satishes both rA and rB, then this can be any one of the 20 specihcations 
in Figure [2 

Consider adaptation to the failure of a functionality. If we were to design a system 
according to one specihcation among those in Figure [T] suppose that we chose, for 
example, S4, so that the system has functionalities rAF4 and rBFl. If rAF4 fails, 
the system would stop working as expected. If it were an Adaptive System, then it 
would be designed so as to switch to another functionality at run-time, for example. 
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Fig. 1 rA and rB are two qualitative requirements that both need to be satisfied by a system. 
rAFl to rAF5 are alternative functionalities that satisfy rA, while rBFl to rBF5 are alternative 
functionalities that satisfy rB. Filled circles are combinations of functionalities that satisfy both rA 
and rB, and are thereby alternative specifications of a system; empty circles denote incompatible 
combinations of functionalities, and are not specifications. 


from rAF4 to rAF2. From the perspective of design-time, this amounts to a switch 
from the design given in specification S4, to that in S2. This is illustrated in Figure 

El 

Now, assume that we have two quantitative variable requirements to satisfy, in 
addition to rA and rB. The first relates to scalability and the second to how the 
system compares to its competitors. Let Varl be the variable in the first, and Var2 
in the second quantitative variable requirement. Varl can be “number of users that 
can simultaneously use the system” and Var2 “number of products available for 
purchase”. 

We prefer large to small values for both Varl and Var2, and we cannot accept 
values that are below some threshold. This is drawn in Figure]^ where T1 is the 
threshold for Varl and T2 for Var2, so that the shaded area shows all acceptable 
combinations of Varl and Var2 values. 

If the system were running according to S4, then it satisfies all four requirements, 
as its values over Varl and Var2 are above their respective thresholds. If rAF4 
fails, the system would need to switch from S4 to either S3 or S5 in order to still 
satisfy all four requirements; if it switched to S2, it would satisfy rA, rB, and the 
requirement on Varl, but not the requirement on Var2. 

As long as the system can switch from one specification to any other specifica¬ 
tion, provided that the latter satisfies all requirements and domain knowledge, then 
we can capture with the DRP the problem of designing that system’s specification. 
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Fig. 2 System runs according to specification S4. Then, functionality rAF4 fails, and the system 
activates functionality rAF2 instead, switching thereby from specification S4 to specification S2. 



Fig. 3 Variables Varl and Var2 quantify the level of satisfaction of two quantitative variable 
requirements. Hypothetical simulations of specifications SI to S6 yield values show in the figure. 
T1 is the threshold value for Varl, and T2 for Var2. 














Requirements Problem and Solution Concepts for Adaptive Systems Engineering 


17 


5.2 Switching and Optimality 

Switching to any specification fails to capture that not all alternative specifications, 
that the system can switch to, are equally desirable. The goal is to switch to the 
one that is optimal with regards to the requirements and domain knowledge, that the 
system is sensing. 

This concern with whether the specification to switch to, is the optimal specifi¬ 
cation among those that we can switch to, clearly distinguishes RPAS from DRR 

We said that we prefer higher values of Varl and Var2, or in other words, we 
said that we have non-functional requirements which can be interpreted as suggest¬ 
ing that we prefer higher values of these variables. To make this more precise, we 
need to say which combinations of values we prefer over others. Since the region 
above the thresholds T1 and T2 is large, it is interesting to indicate (i) the shape 
of indifference curves in that region, and (ii) the direction where these indifference 
curves are over more desirable combinations of Varl and Var2 values. 

Figure shows hypothetical indifference curves in the region above thresholds 
T1 and T2. Each indifference curve is the set of Varl and Var2 value combina¬ 
tions that are equally preferred. So every specification that has Varl and Var2 
values on the same indifference curve as S3 is equally preferred to S3. The arrow 
indicates the direction where Varl and Var2 value combinations are preferred, so 
that any specification on the indifference curve with S5 is strictly preferred to any 
specification on the indifference curve with S3. 

Having clarified with indifference curves what we mean by preference for higher 
Varl and Var2 values, we now go back to Figure[T] There, we had 20 alternative 
specifications. If we want to see them as subsets of S in DRP, they are 20 alternative 
configurations of the same system. Moreover, we said that adaptation amounts to 
moving from one to another of these configurations, based on sensory input of the 
system, and feedback mechanisms that indicate what configuration to switch to. We 
also said that all this can be captured in DRP. 

By adding the two quantitative variable requirements, with their Varl and 
Var2, we had restricted the set of acceptable configurations to some subset of the 
20 shown in Figure 

Given several configurations, all above T1 and T2 thresholds, and all satisfying 
rA and rB, which one should we choose? 

The answer is simple: given the indifference curves, we should choose any con¬ 
figuration which is on the the most desirable indifference curve. More generally, we 
want the system to switch, every time it needs to adapt, to the configuration that is 
the most desirable, among those that are feasible. 

This is not to say that we cannot capture also this notion of optimality in DRP. 
For example, we can have as the only member of R in DRP, the proposition that 
there should be no feasible configuration which is on a more desirable indifference 
curve than the chosen configuration. We can, therefore see RPAS as a subclass of the 
DRP, although doing so seems rather odd, for there were no considerations of con¬ 
figurations, adaptation, preference, uncertainty, or optimality in defining the DRP. 
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Fig. 4 Hypothetical indifference curves over value combinations of Varl and Var2. One in¬ 
difference curve includes all Varl and Var2 value combinations that are equally desirable. For 
example, any specification on the same indifference curve as S3 is equally desirable as S3. The 
arrow indicates the direction in which value combinations are more desirable. Therefore, S5 is 
preferred to S3, and S3 is preferred to S4. 


6 Requirements Problem and Solution Spaces 

We start with two simple definitions; they clarify what we will mean by the terms 
Specification and Solution in the rest of the paper. 

Definition 6. Specification: A Specification is a description of a design of a system. 

Definition 7. Solution: In a given RP, a Solution is a Specification such that, if 
we chose to commit to making the system according to that Specification, then we 
consider that we have solved that RP. 

Another way to think about the Solution and Specification, is that the Specifica¬ 
tion is a candidate Solution in an RP that we are solving. 

Hereafter, and in general in the paper, if we define a term, then we will capitalise 
it throughout. The capitalised term should be read as it was defined. 

The conclusion that not all RPs are subclasses of the DRP, and that RPAS is also 
not a subclass of the DRP, means that there are many RPs that we may want to define 
and solve, and that each may have many Specifications, some or one of which is the 
optimal one, and thereby the Solution. 

The goal now is to narrow down these ideas, and we will do this by defining the 
notions of Problem Space and Solution Space. If we agree on what these spaces are, 
then it will be easier to define the RPAS. 
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6.1 Problem Space 

We call it the Problem Space, because it has some number of dimensions, and each 
dimension corresponds to something that we can evaluate a Specification for. 

For example, if we have a DRP instance with one requirement |R| = 1 and no 
domain knowledge |/r| =0, then the Problem Space would be one-dimensional, a 
line, where each point refers to a level of satisfaction of the single requirement in 
R. If that requirement had a scale of satisfaction with 10 levels, then there would 
be exactly 10 points in the Problem Space. If it had two levels of satisfaction - 
satisfied or failed - then the Problem Space would have two points only. If the level 
of satisfaction was a real number between some maximum and minimum, then there 
would be an infinite number of points in the Problem Space. 

In an RP which satisfies the R and the K properties, we can evaluate if a Spec¬ 
ification satisfies a requirement, so that members of R would induce dimensions in 
the problem space. But we can also evaluate if the Specification satisfies or fails 
constraints from K, which is why members of K would also induce dimensions in 
the problem space. 

To remain general, we need to avoid being constrained by the DRP. In particular, 
we want to be independent from the properties K and R, that is, from the catego¬ 
rization that the DRP imposes on criteria that Specifications are evaluated against. 
We do this by introducing the concept of Criterion in the definition of the Problem 
Space concept. 

Definition 8. Problem Space: Set of points, where each coordinate of each point 
corresponds to the value of a Criterion. 

Definition 9. Criterion: A variable, such that (i) we can establish its value for each 
Specification, and (ii) some of its values are more desirable than others, regardless 
of which Specification is being evaluated. 

Various kinds of information used when solving an RP can produce Criteria for 
a Problem Space. The obvious example are requirements that are either satisfied or 
not. For each of those, we have one Criterion, non-functional requirements are more 
complicated, since it can be hard to find suitable variables to measure their level of 
satisfaction. Such variables would correspond to Criteria. 

Criteria do not come from requirements only. Domain knowledge may indicate 
laws that the system-to-be should comply with, and each norm from the law may 
give a Criterion. Each of those Criteria would have two values, does comply and 
does not comply. 

There is a nuance to keep in mind: some requirements, for example, may be re¬ 
finements of other requirements, so that there can be relations between the value of 
different Criteria for the same Specification. For example, the value of a Specifi¬ 
cation on one Criterion may be fully determined by values of that Specification on 
other Criteria. The following example illustrates this. 

In ambulance services, suppose that we have this statement: “Ambulances arrive 
at their incident locations”. 
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We will take this to be a requirement, and abbreviate it with R (AmbArrive), 
where AmbArrive refers to the statement above, and R that this statement is a 
requirement. 

We can make this requirement more detailed, by saying that it will be satis¬ 
fied if these more specific requirements are satisfied: R(IdentAmb) for “Iden¬ 
tify available ambulances”, R (ChooseAmb) for “Choose ambulance to dispatch”, 
R{AssignAmb) for “Assign ambulance to incident”, R (MobilizeAmb) for 
“Dispatch the ambulance to the incident location”, R (Conf irmMob) for “Con¬ 
firm that the ambulance was dispatched”. 

In other words, we refined R (AmbArrive) onto five other requirements. As 
this means that if all five are satisfied, then R (AmbArrive) is satisfied, it also 
means that in the Problem Space: 

• there is a Criterion for each of the six requirements above, 

• each of these Criteria allows two values, satisfied or not satisfied (this is the case 
if we do not want to allow degrees of satisfaction for these requirements, but we 
see them as either satisfied or not), 

• there is a function that ties the satisfaction of the five more specific requirements 
with the refined requirement, in that the latter is satisfied only if all five are satis¬ 
fied. This means that the value of the Criterion corresponding to R(AmbArrive) 
is function of values for Criteria for the five other requirements. 

In the example in Section [5T| we had two requirements, rA and rB. We eval¬ 
uated each as either satisfied or not. It follows that our Problem Space there has 
two Criteria, rl and r2. If we further assume that the satisfaction of one require¬ 
ment is independent from the satisfaction of the other, then any Specification can 
correspond one of four points in the Problem Space. This is illustrated in Figure]^ 
A more complicated Problem Space may involve non-functional requirements, 
which give Criteria that can take a real value from some range. Each Specification 
evaluates to one value of that Criterion, so that the number of positions that Specifi¬ 
cations can take is infinite. 

Figure illustrates the Problem Space defined by one binary requirement and 
two variables quantifying the degree of satisfaction of non-functional requirements. 
There, the Problem Space amounts to two planes, one where a Specification has the 
coordinates {rA not satisfied,xl,yl) and the other where a Specification’s coordi¬ 
nates are {rA satisfied,x2,y2)-, xl and x2 are values of Var 1, yl and y2 of Var2. 


6.2 Problem Instances 

It is important to observe that Criteria define a Problem Space, not a single RP to 
solve. 

If we have a Problem Space made of n Criteria, we can choose exactly one RP 
to solve by choosing one value of each Criterion. By choosing a point in the Prob¬ 
lem Space, we have identified the exact requirements, domain knowledge, etc., that 
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Fig. 5 Problem space defined by two requirements rA and rB, both with two levels of satisfaction. 
The satisfaction of one is independent from the satisfaction of the other. The black circle is a 
position in the Problem Space where both requirements are satisfied. 


any Specification should satisfy. We capture this in our terminology by adding the 
following. 

Definition 10. Problem Instance: A Problem Instance in a Problem Space is an 
assignment of a value to each Criterion in that Problem Space. 

The above is important, because it suggests that, when doing RE, we can be solv¬ 
ing one RP instance, or we may have the freedom to choose the Problem Instance 
instance to solve. This choice may be due to necessity, such as when it is not feasible 
to design the system in such a way, that it maps exactly to the Criteria values chosen 
in the Problem Instance. 

For example, in Figure the empty circle is a Problem Instance, and if choose 
to solve it, then we have decided to look for Specifications which do not satisfy the 
requirement r A. If we choose to solve the Problem Instance marked with the black 
circle, then we will be looking for Specifications that satisfy the requirement rA. 


6.3 Solution Space 

The Solution Space is made of dimensions that correspond to properties which we 
can design into the system. 

For example, if we have in the Problem Space a Criterion that measures the 
response time of a server (or more abstractly, the responsiveness of the system), then 
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Fig. 6 Problem Space defined by the binary requirement rA and two non-functional requirements 
from Figures[T]and[^ Black circle is a point where rA is satisfied, while the empty circle is a point 
where rA fails. 


in the Solution Space, we are interested in what we should build into the system, to 
make sure that it will achieve some value over that Criterion. 

We introduce the following terms. 

Definition 11. Solution Space: Set of points, where each coordinate of each point 
corresponds to the value of a Parameter. 

Definition 12. Parameter: A variable, such that we can choose its value for each 
Specification, and this value is expected to influence the behaviour of the system- 
to-be in some predictable manner. 

We chose the term Parameter, because its dictionary definition indicates it is a 
variable whose value we choose. This is very different from Criteria, since the idea 
for them is that we obtain their values through measurement or otherwise, rather 
than set or choose their values. 

Parameter is a general notion, intended to be independent from what one chooses 
to call the fragments of a Specification. A two-valued Parameter can capture the 
common notion of functionality, as something that is either present or absent in 
the system-to-be. When it can take more values, a Parameter can capture the idea 
of parameterisable functionalities of the system-to-be; for example, that we can or 
need to decide the resolution of a screen in an operating system, the number of 
ambulances in a system delivering emergency services, and so on. 

As for the Problem Space, there can be relations between values on various Pa¬ 
rameters in the Solution Space; for example, a functionality F1 may be decomposed 
















Requirements Problem and Solution Concepts for Adaptive Systems Engineering 


23 



Fig. 7 Solution Space that has 8 points, defined by three Parameters, FI, F2, and F3, each of 
which can either be on (in a Specification of the system-to-be) or off (not in a Specification). On or 
off value of one Parameter is assumed independent from the on or off values of other Parameters. 
The black circle is a position where all three are included in the Specification. 


into two different functionalities Fla and Fib, so that the presence or absence of 
FI depends on the presence or absence of both Fla and Fib. 

Figure [^illustrates a Solution Space defined by three Parameters, each of which 
can be either included in a Specification, or excluded from it. Figure illustrates 
the Solution Space generated by two two-valued Parameters, and a Parameterwhose 
value can be any real number between 1 and 10. 


6.4 Double Decision-Making 

Problem Space and Solution Space concepts make it clear that RE may involve 
choosing both the Problem Instance to solve, and the Specification which solves 
it. For example, it may be that we change from one Problem Instance to another 
because of feasibility, while implementation cost could lead us to change from one 
Specihcation to another. 

Problem-solving in RE involves this double and interdependent decision-making, 
of choosing the Problem Instance and choosing the Specihcation. If we were to de¬ 
sign a process for problem-solving, then we would need to decide, for example, if 
we are going to hrst choose a Problem Instance, and then design the Specihcation 
to solve it, or if we would hrst choose a feasible Specihcation, and then see how to 
make the least changes to it to make sure it satishes the Problem Instance closest 
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Fig. 8 Solution Space made of all points on the four thick black lines, defined by two two-valued 
Parameters FI and F2, and one Parameter FPar, which can take a real value between 1 and 10. 


to the one we should solve. Or if we should do something else, such as distinguish 
mandatory from nice-to-have values of Criteria, and choose only among those Spec¬ 
ifications, which satisfy all of the mandatory Criteria values. 

For example, the DRP gives requirements and domain knowledge, so that we are 
given the Problem Instance, and we need to incrementally design a Specification, 
which should be the Solution to exactly that Problem Instance. This is because all 
members of R and all members of K must be satisfied, so that all values of all Criteria 
in this Problem Space are already decided. 

This double decision making is an additional argument supporting the idea that 
DRP is not the root of a taxonomy of RPs. There is no particular reason why we 
must first choose one Problem Instance and then look for its Solution in the Solu¬ 
tion Space. It can happen that we start from unrealistic requirements, and/or from 
conflicting requirements, and that, as we proceed in problem-solving, we have to re¬ 
vise the Problem Instance we are solving - that is, we need to move in the Problem 
Space, not only in the Solution Space. And this is the implicit assumption in RE re¬ 
search concerned with requirements inconsistency m, conflicts EH, and obstacles 
to requirements satisfaction ISS). 


6.5 Relating the Problem Space and the Solution Space 

There are two kinds of relations between the Specifications in the Solution Space 
and the Problem Instances in the Problem Space; 
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Fig. 9 Mapping Specifications from the Solution Space (left) to Problem Instances in the Problem 
Space (right). The dotted lines are instances of the Solve relation. Two Specifications X and Y 
are marked in the Solution Space. If we are looking to solve the Problem Instance where rA is 
satisfied, then Specification Y will not be appropriate, as it maps to the Problem Instance in which 
the requirement rA fails. The Problem Space shown involves non-functional requirements, whose 
degree of satisfaction is quantified with variables Varl and Var2. 


1. The Solve relation, between one Specification and one Problem Instance, used to 
indicate that the former can be a Solution to the latter, 

2. The Depend relation, when it makes the values of some Criteria (not necessarily 
all) depend on values of some Parameters. 


6.5.1 The Solve Relation 

By being a point in the Solution Space, the Specification can be seen as the synthesis 
of all our decisions, on what values to give to all Parameters. 

Measurement or simulation of a Specification maps it to a Problem Instance in 
the Problem Space. (Measurement and simulation are not the only ways; there are 
others, such as relying on expert opinion, but this does matter much in this discus¬ 
sion.) We say that if the Specification X maps to the Problem Instance Y, then X 
solves Y. But since there can be many Specifications that can map to the same Prob¬ 
lem Instance, we will say that X is the Solution of Y only if it is the one Specification 
chosen among all others that are considered during problem-solving. 

We need a name for the relation between a Specification in the Solution Space 
and a Problem Instance in the Problem Space. This relation should exist between 
a Specification and a Problem Instance, if we believe that, when that Specification 
is implemented, measuring it over the Criteria in the Problem Space will result in 
exactly those Criteria values that the Problem Instance has. 

Definition 13. Solve is a relation from one Specification in the Problem Space to 
one Problem Instance in the Problem Space. We say that Specification A Solves 
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Problem Instance B if and only if we believe that, if the system is made according 
to Specihcation A, and we measure the system according to the Criteria that define 
the Problem Space, then we will obtain values of these Criteriawhich correspond to 
the values that they have in Problem Instance B. 

For a given RP, instances of the Solve relation are the result of problem-solving, 
as they can be found only after at least one Specification and one Problem Instance 
have been identified. 


6.5.2 The Depend Relation 

The Depend relation is between Parameters and/or Criteria, when their values are 
interdependent. It is not restricted to being between individual points in the Problem 
Space and the Solution Space. It can be used to represent that, for example, the value 
of a Parameter depends on the values of other Parameters and/or Criteria, that the 
value of a Criterion depends on values of other Criteria and/or Parameters, that the 
value of a Parameter has to be in some range, and so on. 

A simple way to think about the Depend relation, is that, any function that relates 
the values of Parameters and/or Criteria is an instance of the Depend relation. 

Definition 14. Depend: Given some variables, which may be Criteria and/or Pa¬ 
rameters, if their values are interdependent, then there is an instance of the Depend 
relation between these variables. 

Figure [T^ gives an illustration of a function where the value of Criteria depend 
on the value of Parameters. 


7 Optimal Specifications in Problem Spaces 

Our definition of the Solution concept in Section only says that the Solution is 
that Specification which we commit to, as the Specification which the system-to-be 
should implement. 

In contrast, the discussion of optimality in Section used the obvious premise 
that it is desirable, in general, to commit to the Specification which is somehow the 
“best” relative to those Specihcations that are considered during problem-solving. 

The goal now is to relate these two ideas, of optimality of, and commitment to a 
Specihcation, and do so using the concepts and relations introduced so far. 

Relating commitment and optimality means using the following revised Solution 
dehnition. 

Definition 15. Solution (replaces Definition |^: In a given RP, and thereby for its 
Problem Space and Solution Space, the Solution is the Optimal Specihcation. 
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Fig. 10 If a point is chosen along the highlighted line in the Solution Space (left), then this results 
in a point on the highlighted area in the Problem Space (right). The figure illustrates the Depend 
relation between the values of the Parameters Fpar, FI, and F2, and the values of Criteria rA, 
Varl, and Var2. 


The revision reflects the idea that relating commitment to optimality amounts to 
asking that we commit to the Specification which satisfies those properties that op¬ 
timality imposes. This is different from the original Solution in Deflnition|^ where 
the only property of the chosen Specification is that we commit to it, regardless of 
how exactly it relates to other Specifications. 


7.1 Preference and Utility in Problem Spaces 

The revised Solution concept leads to the question of when a Specification is also an 
Optimal Specification, in the terminology of Problem Spaces and Solution Spaces. 

To answer this, recall that Specifications in themselves are interesting only be¬ 
cause they describe systems, which, if they are implemented accordingly, would 
achieve specific values over all of the Criteria in the Problem SpaceQlt is because 
it manages to map to some Criteria values that a Specification, or a set of Specifica¬ 
tions is of any relevance in problem-solving. 

The fact that we are designing Specifications because we are in fact interested in 
some values of Criteria, means that whether a Specification is better than another 
is an issue that is solved not by looking only at the Solution Space, but at where a 
Specification maps to in the Problem Space. 

* As we cannot make all systems that implement all the Specifications, and then measure values of 
Criteria on systems themselves, we make the simplifying assumption that it is a Specification that 
maps to points in the Problem Space, not the system; this changes nothing in this discussion, other 
than pointing out that the mappings between the Solution Space and Problem Space will often 
simply be based on our experience, predictions, speculation, and such, not on actual measurement. 
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Therefore, whether a Specihcation is the Optimal Specihcation depends on where 
it maps in the Problem Space, since different Criteria values are not equally desir¬ 
able. This was illustrated with indifference curves in Figure earlier: we may be 
indifferent between some value combinations, which we can represent with an in¬ 
difference curve, while different indifference curves reflect that we can evaluate 
some value combinations as strictly more desirable than others. 

In the ideal and almost certainly infeasible case, we would have information 
about preference between every combination of values of independent Criteria. This 
would give us the indifference curves for these combinations, and also the corre¬ 
sponding utility function. In more realistic cases, we may be able to find a partial 
order preference relation, which compares some combinations, perhaps over a sub¬ 
set of Criteria in the Problem Space. 

In any case, however, the important observation to make is that in order to say 
which regions of the Problem Space are more desirable than others, it is necessary 
to have information about the relative desirability, that is, of preference of Criteria 
value combinations. 

As a brief digression, we recall here how the notions of preference, utility, and 
indifference curves are related in general, in economics. The term preference is used 
here to mean preference relation, the binary relation that indicates the relative de¬ 
sirability between two things; in this paper, it is the binary relation that compares 
the relative desirability of Criteria values, be they values of the same Criterion, or 
of different Criteria, or of value combinations of Criteria. Utility is a quantitative 
representation of information in a preference relation. If a preference relation, for 
example, over different values of a single Criterion, is transitive, complete, and con¬ 
tinuous, then we can dehne a corresponding utility function which is continuous. 
An indifference curve is a set of different combinations of things compared in terms 
of preference, which are all equally preferred. A utility function reflecting that pref¬ 
erence relation will return the same utility value for all members of that set. The 
same utility function gives many indifference curves, as there can be several sets of 
equally preferred combinations, such that combinations from different such sets are 
not equally preferred. As a final remark, utility is a generic notion, which can have 
different interpretations, and the specihc meaning it will have depends on what one 
chooses to quantify desirability with. 


7.2 Utility Representation with Criteria and Depend Relations 

This preference information can be represented using the notions which were al¬ 
ready introduced, namely. Criteria and the Depend relation. To add a utility func¬ 
tion, add a Criterion whose values are read as utility values, and a Depend relation 
that specifies which other Criteria values determine the utility value. This is the il¬ 
lustrated in Figure by adding a utility Criterion U (Var 1, Var2 ) which gives 
the utility value for combinations of Varl and Var2 Criteria. 
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Fig. 11 The figure on the left shows a part of the Solution Space, borrowed from Figure]^ S3, S4, 
and S5 indicate mappings of three different Specifications to this part of the Problem Space. The 
three are above the threshold values T1 and T2 . Each is on a different indifference curve, indicating 
that they are not equally preferred. The part on the right adds a Criterion U (Var 1, Var2 ) which 
gives the utility value of value combinations of Var 1 and Var 2. Note that the figure on the right 
is a simplification, as the two points S4 and S5 are points on a three-dimensional surface; the shape 
of the indifference curve hints at the shape of that surface. 


It is important to note that there can be different utility Criteria in the same Prob¬ 
lem Space. This can be due to the fact that we may know preferences between value 
combinations of some Criteria, but not of others; or it may reflect differences in 
preferences between stakeholders, in which case we could have different utility Cri¬ 
teria for different stakeholders. Another important remark is that any definition of 
the dependence between the value of some Criteria and the value of other Criteria, 
be they utility Criteria or otherwise, are defined by a function that consequently is 
an instance of the Depend relation. 


7.3 Decision Rules 


Even in the trivial example introduced in Section 5.1 we can have many different 


preference orders, and thereby different utility functions. For example, there can be 
a preference order over values of Varl, another over those of Var2; if there are 
three stakeholders. A, B, and C, and they all have their own preferences over the 
values of these Criteria, then we might have nine preference orders in total; worse, 
we may not have a rule that tells us how to obtain preferences over combinations 
of Varl and Var2, from those that we have, over only values of Varl and only 
values of Var 2. 

As soon as there are two preference relations, it is necessary to explain how they 
are used together to compare Problem Instances to which Specifications map in the 
Problem Space. 

This explanation is called the Decision Rule, and can take various forms. 
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In the example illustrated in Figure we may want to do one of the following; 

• Maximize the value of U {Var 1, Var2), 

• Maximize the value of Var 1, 

• Maximize the value of Var 2, 

• And so on. 

Each item gives the condition that a Specification should satisfy, in order to be 
the Optimal Specification. In the first item above, the Decision Rule means that the 
Optimal Specification is the Specification which maximizes the value of U (Var 1, 
Var2 ). In the second item, notice that the utility function is not given, but is im¬ 
plicit: namely, utility is independent from the value of Val2, and increases with the 
increase in Vail. The third item is the opposite case. 

Definition 16. Decision Rule: A Decision Rule is the Criterion, such that in a given 
set of Specifications, the Specificationwhich has the highest value on that Criterion, 
is the Optimal Specification. 

The Decision Rule is a special Criterion, as it will single out the Optimal 
Specification among those Specifications that we are considering. Its value may, 
and often will be the result of combining values of other Criteria, such as when 
U{Varl,Var2) is the Decision Rule. 


8 Requirements Optimisation Problems 

The Decision Rule definition, together with the notions we had introduced so far, 
introduces a new class of RPs, all of which include the Decision Rule defined above. 
They are called Requirements Optimisation Problems (ROPs). 

Because they all include the Decision Rule, they are not a subclass of the DRP 
ROPs are important for the RPAS, as we will argue in Sectionj^that the RPAS 
amounts to a set of ROPs, together with some additional constraints on that set. 

This section first defines the ROP, and then illustrates how the DRP, if we only 
apply one change to it, becomes a subclass of the ROP. 


8.1 Problem Statements 

Solving an ROP involves doing design and doing decision-making. 

Here, doing design means doing four tasks, and not necessarily in the sequence 
given below: 

1. Constructing the Problem Space, by finding and defining Criteria, and defining 
Depend relations between these Criteria, when we know that there are corre¬ 
lations between their values, or have other reasons to believe that their values 
determine one another. 
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2. Constructing the Solution Space, by identifying and defining Parameters, and the 
Depend relations between the Parameters. 

3. Defining Depend relations between Parameters and Criteria, so as to clarify how 
the choices of values of the former relate to the satisfaction of the Criteria. 

4. Choosing the Decision Rule, and defining the Depend relation which makes its 
value depend on values of other Criteria in the Problem Space. 

Doing decision-making here means identifying and committing to values of Pa¬ 
rameters which, relative to any other combination of Parameter values, result in the 
highest value of the Decision Rule. 

This separation between design and decision-making is introduced to highlight 
that there are two kinds of tasks in ROP problem-solving. The aim is not to suggest 
that they are necessarily done in sequence, that we first have to do all related to 
design, and then do the decision-making. The separation still fits incremental design, 
which, in this perspective, amounts to a sequence of activities, some of which are 
focused on design (such as, adding new Criteria and Parameters, choosing values 
thereof, etc.) and some of which are concerned with decision-making (trying to find 
values of Parameters) and can initiate the next design iteration (such as if we fail to 
find the Parameter values, which may lead to changing Parameters, Criteria, Depend 
relations, and so on). 

The two problems are defined as follows. 

Definition 17. Requirements Design Problem (RDP): Given the information about 
the stakeholders’ expectations, and the information about the environment of the 
system-to-be, define (i) the Problem Space, (ii) the Solution Space, (iii) the Depend 
relations over Criteria in the Problem Space and the Parameters in the Solution 
Space, and (iv) the Decision Rule. 

Definition 18. Requirements Optimisation Problem (ROP): Given (i) a Problem 
Space, (ii) a Solution Space, (iii) a set of Depend relations between Parameters 
and/or Criteria, (iv) a Decision Rule, and (v) a set of Parameters in the Solution 
Space whose values have not been set, called the Decision Set, find the values of 
Parameters in the Decision Set, such that there is no other combination of values of 
these same Parameters, which returns a higher value of the Decision Rule. 

As Criteria and Parameters are variables, and Depend relations are functions over 
these variables, the ROP can be rewritten as follows: 

Maximise fo(x) 

subject to fi(x) = bi, for i = 


where: 

• X is the Decision Set, that is, a set of Parameters in the Solution Space, whose 
values should be set, 

• /o(x) is the Depend relation that returns the value of the Decision Rule in the 
Problem Space, 

• Each fi{x) = bi, for / = 1,..., n is a Depend relation instance. 
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8.2 An Illustration: Converting the DRP into an ROP Subclass 

The aim in this section is to illustrate how ROPs are related to the DRP. We do 
this by rewriting the DRP as a ROP subclass. That subclass will be called Revised 
Default Requirements Problem (RDRP). 

Defining RDRP involves answering the following questions: 

1. What are K, R, S of the DRP in the ROP? 

2. What are the Depend relations in DRP? 

3. What is the Decision Set in DRP? 

4. What is the Decision Rule in DRP? 

The DRP uses the syntactic consequence relation h, leading us to assume that it 
is of classical, two-valued logic, so that members of K, S, and R can either take the 
value 0 or 1. Note that these values have a different reading depending on them being 
for members of K, S, or R: in R, “1” tends to read “satisfied”, “achieved”, etc.; in K, 
“1” can read “maintained”, “satisfied”, etc.; and in S, “1” can read “implemented”, 
“configured”, or otherwise, along these lines. 

It follows that the RDRP has only integer binary variables. 

In the terminology of Problem Spaces and Solution Spaces, variables that corre¬ 
spond to members of K and R are Criteria in RDRP, and define the Problem Space; 
variables that correspond to members of S are Parameters, and define the Solution 
Space. 

The Depend relations in RDRP correspond to the relations between the members 
of K, S, and R. For example, if the value of a variable w, depends on the value of 
other variables yi,..., then we define a Depend relation w, — f{yiuj^) = 0. 

We will have such Depend relations, because if a requirement r A is, for example, 
refined by two other requirements rAl and rA2, then rA is satisfied if and only if 
both rAl and rA2 are satisfied. In RDRP, this is captured by a Depend relation. 

In the DRP, R is given and must be satisfied, which in the RDRP means that 
the values of all variables from R are set to 1, and they therefore cannot be in the 
Decision Set. K is also given, and since R and S should be consistent with it, we can 
also set all K variables to 1. 

Variables from S in the DRP remain as the members of the Decision Set of the 
RDRP. If an S variable depends on the values of other S, K, or R variables, then we 
will exclude it from the Decision Set. It follows that the cardinality of the Decision 
Set does not need to equal cardinality of S. 

All members of K and R are equally preferred, as it is equally important to satisfy 
every member of R, and to maintain every member of K. We concluded earlier that 
there are no means to compare specifications in the DRP. There is no information 
about preferences in the DRP. 

But once we allow alternative refinement of same requirements, we have alterna¬ 
tive Specifications to choose from, and we want the RDRP to reflect this. Suppose 
that we allow any member of K, R, S to be refined. This means that refining R gives 
us another set of requirements, which includes requirements that refine those in R. 
Let that set be ref{R), and let ref{K) and ref{S) be for K and S, what ref{R) is for R. 
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The resulting RDRP is to find a subset of ref{S), such that, if all Parameters in 
that subset are set to 1, then all Criteria from K and R obtain the value 1. As there 
are is no preference information in the DRP, it is unclear what the Decision Rule 
should be. 

The simplest choice we saw for the Decision Rule in the RDRP, is that it is equal 
to the sum of the members of ref{S), meaning that we want to find the smallest subset 
of ref{S) which manages to result in the assignment of the value 1 to all Criteria 
corresponding to members of K and R. So we want to maximise the following: 


- E 

XierefiS) 

In addition to the Depend relations for refinements, we need the following De¬ 
pend relations to guarantee that the Solution must assign the value 1 to every Crite¬ 
rion from K and R\ 


E X/ = 1^1 

y j^R 

Y^zi = |/:| 

zieK 

Note that, since every x,- in ref{S) is a binary variable, the solution to RDRP will 
be the smallest subset of ref{S), which satisfies all Depend relations. This modi¬ 
fies the Decision Ruie Property from the DRP; that property is neutral about the 
specifics of S, as long as it satisfies the Consistency and Satisfaction properties. 
This makes the RDRP a different problem than DRP, and this is not necessarily a 
relevant problem: the number of Parameters set to 1 in ref{S) has, in itself, nothing 
to do with the quality expected from the system-to-be. 


9 The Requirements Problem for Adaptive Systems 


This section introduces the definition of the RPAS in the following steps. In the 
first step, in Section 9.1 we recall the key ideas in RE for ASs. In Section 9.2 we 


relate these ideas to the terminology of Problem Spaces and Solution Spaces, the 
RDR and the ROP. This leads us in Section [93l to the definition of the design and 
decision-making problems that form the RPAS. 
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9.1 Key Ideas in Requirements Engineering for Adaptive Systems 

In order to adapt to changes, the Adaptive System has to be capable of detecting 
changes; it can only respond and adapt to those changes that it can detect. 

To detect changes, the Adaptive System has to gather data about events in its op¬ 
erating environment and about the functioning of its own components. At all times, 
and on the basis of these observations, the Adaptive System has to estimate the level 
to which it satishes the stakeholders’ requirements. If the levels of satisfaction are 
inadequate, the Adaptive System has to make changes to what it does in order to 
satisfy the requirements. 

The AS changes its behaviour via feedback loops. A feedback loop dehnes the 
variables whose values need to be monitored; the values would be collected by sen¬ 
sors, or would be functions of variables whose values the sensors collect. When the 
values fall out of the predehned and allowed range, this triggers functionality in the 
AS, dedicated to make changes to the operation of the AS. 

Capability to adapt requires a hierarchy of functionality in an AS. The lowest- 
level functionality interacts with the environment; the next level is functionality that 
enables feedback loops, which monitor signals from sensors that monitor the envi¬ 
ronment and the functionality at the lowest level; the second level is functionality 
that enables feedback loops that monitor and manipulate the feedback loops at the 
hrst level; and so on. 

The above leads to key observations about the run-time of Adaptive System, (i) 
The level at which requirements are satished will vary, due to failure in the system 
and change in its environment, (ii) It is necessary to monitor the level of satisfaction 
of requirements, in order to know when the system needs to adapt, (iii) When the 
system adapts, it may have different ways of adapting, and each of these ways may 
have a different impact on requirements satisfaction levels, (iv) Whenever it needs to 
adapt, the system should adapt in the way that optimizes the levels of requirements 
satisfaction, relative to the newly observed failure of a component, or of a change in 
the environment. 

The observations about run-time have important implications for the design-time 
of Adaptive Systems. 

Due to observation (i), it may be too idealistic and impractical to think of re¬ 
quirements as being either satished or not, since this may lead to too many failed 
requirements, too often. It can be more practical, therefore, to dehne multivalued 
scales of requirements satisfaction, where failure equates to only some of many val¬ 
ues. This is done through the relaxation of requirements 143] 113 H], where the 
idea is to replace binary levels of satisfaction with, for example, continuous scales 
of satisfaction, or by letting the requirement be binary, but tracking the frequency 
of them being satished or failing, then using that frequency as the measure of the 
degree to which these requirements are satished. 

Observation (ii) suggests that it is necessary, at design-time, to dehne the levels 
of requirements satisfaction that trigger adaptation. If the requirement has a binary 
satisfaction scale, being either satished or not, it may be relevant to dehne the mini¬ 
mal probability of observing its satisfaction; for example, in an ambulance dispatch 
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system, asking for the probability of at least 0.95, that an ambulance arrives to an 
incident location within 5 minutes of being dispatched to it. This would translate, 
at run-time, into looking at the frequency of incidents where the ambulance arrived 
5 minutes or more, and triggering adaptation if that frequency is 5% or more of all 
incidents to which an ambulance was dispatched. If the requirement has a scale with 
many levels of satisfaction, then a threshold value has to be dehned on that scale, 
such that, when the satisfaction is below threshold, the system needs to adapt. This 
has led to research on awareness requirements l(55l . which are used to define these 
thresholds for triggering adaptation. 

At run-time, when awareness requirements are satisfied, feedback loops become 
active, and the system adapts. Because of observations (iii) and (iv), it is necessary 
to define at design-time the requirements that the system should satisfy when adapt¬ 
ing. These are the so-called evolution requirements ll54l . and place constraints on 
how the system adapts. In the terminology of research on the RE for Adaptive Sys¬ 
tems, evolution requirements place constraints on the range of reconciliation tactics 
imiiaisi] that the system may choose to apply, when adapting. The ambulance 
dispatch system could adapt to the failure in its component that records ambulance 
location, by requiring that control assistants who dispatch ambulances, record these 
locations manually, or by relying on the record of ambulance location by the part 
of the system which is located in each ambulance. An evolution requirement may 
indicate that control assistants should not manually record information, unless more 
than one of the automatic data recording components fails; this would exclude the 
second adaptation in the example. 


9.2 Premises for the definition of the RPAS 

The aim in this section is to relate the key ideas from existing research, to the termi¬ 
nology of Problem Spaces, Solution Spaces, the RDP, and the ROP. 


9.2.1 Monitoring 

The ability of an AS to adapt to changes requires that the system can detect changes. 
We introduce two terms, in order to talk about the extent of changes that the AS is 
designed to detect. 

Definition 19. A Monitored Variable is a variable whose values the Adaptive Sys¬ 
tem collects and whose changes of values can trigger adaptation. 

Definition 20. The Monitoring Scope of an AS is the set of all of its Monitored 
Variables and, for each variable, the range of values that the Adaptive System can 
detect. 

The Monitoring Scope describes what the AS is able to detect as change in its 
environment, and change in its own functionality. These changes are detected via 
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sensors. The variety and the specifics of the sensors that an AS has, determine its 
Monitoring Scope. 

If something in the environment, or in the AS itself changes, but there are no 
Monitored Variables to reflect that change, then the AS will ignore it. 

The Monitoring Scope reflects the changes that were anticipated at design-time. 
All other changes, which the Monitoring Scope cannot detect, remain as unantici¬ 
pated changes. It is in this sense that we talk about scope in Monitoring Scope, as 
the scope of changes that have been predicted and considered as particularly rel¬ 
evant at design-time, regardless of how relevant they may actually prove to be at 
run-time. 

The design of the Monitoring Scope involves choosing the Monitored Variables, 
based on the sensors that can be built into the AS, and the Depend relations between 
Monitored Variables and the Parameters in the Solution Space, and the Criteria in 
the Problem Space. Without these Depend relations, it is unclear why sensors would 
be used at all, or why and when the AS should adapt. 

Monitoring the level of requirements satisfaction here means having Monitored 
Variables that are equal to some of the Criteria in the Problem Space. Monitoring the 
satisfaction of domain knowledge also means that the Monitoring Scope will include 
Monitored Variables that are equivalent to some Criteria, when these Criteria reflect 
domain knowledge. We may also have Monitored Variables that monitor Parameter 
values, as we want to know when failure happens, that is, when actual Parameter 
values are not those defined in the Solution. 


9.2.2 Change 

The Monitoring Scope is unlikely, in general, to be such that it enables the AS to 
detect all relevant changes in its functioning, its environment, and in the expectations 
of its stakeholders. This is the case as we cannot, at design-time, anticipate all that 
could potentially change, and to which the system should adapt. 

Independently from the Monitoring Scope, there is what we call the Change 
Scope, denoting the variety of phenomena in, or outside the AS, which may occur, 
and to which the AS may need to adapt. 

The Change Scope is not limited to phenomena that can cause the AS to fail to 
satisfy its design-time requirements, and/or to phenomena that put it at odds with its 
environment. 

Stakeholders need to perceive the services that the AS delivers as being of high 
quality. People’s evaluations of service quality reflect their own comparisons be¬ 
tween expectations and experience with the service im m 113 |63l |33. While 
design-time requirements are fixed, we may well have an AS that does achieve 
these requirements, but is perceived as being of low quality; stakeholders’ expec¬ 
tations may have changed, enlarging the gap between what they expect, and their 
experience of the AS. The following definition of the Change Scope reflects this. 

Definition 21. The Change Scope is the set of variables that describe the phenom¬ 
ena in the environment of the AS, and/or the system itself, are such that the values 
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of these variables can change independently from the system’s operation, and these 
changes influence the stakeholders’ perception of the quality of the AS. 

At design-time and run-time, then, there can be many variables in the Change 
Scope that the system would ideally monitor. Their relevance may become apparent 
only after some phenomena occur at run-time and affect the stakeholders’ perception 
of quality of the AS. In such cases, the engineers need to determine how to measure 
these phenomena, which sensors to use to collect measurements, and thereby add 
new variables to the Monitoring Scope. 

In the terminology of the Monitoring Scope and the Change Scope, the design 
of feedback loops can be described as the task of identifying phenomena that can 
influence stakeholders’ expectations, finding ways to measure them, adding these 
variables to the Change Scope. Next, it is necessary to determine how these vari¬ 
ables are related to Criteria and Parameters. All such variables are candidates for 
becoming Monitored Variables. 

It is unlikely that we can identify every variable in the Change Scope. Of those 
that we do manage to identify, we may also be able to make only some into Mon¬ 
itored Variables, due to, for example, there being no sensors that are capable to 
capture their values. 

The conclusion that is important for the definition of the RPAS, is that the design 
part of the RPAS involves finding and choosing variables in the Change Scope, that 
need to be made into Monitored Variables in the Monitoring Scope, as it is unlikely 
that we can ensure that the Monitoring Scope fully covers the Change Scope. 


9.2.3 Stability and Adaptation 

We will use the term event to refer to any change of values of variables in the Change 
Scope; an event can be the result of a failure of a component of the AS, a drop in 
the level to which the AS satisfies a requirement, a change in the conditions in the 
operating environment of the AS, and so on. 

The reason for having Monitored Variables in the first place, is because their 
changes of values result in changes of values of Criteria in the Problem Space and/or 
Parameters in the Solution Space. 

The run-time of the AS is, then, a sequence of two kinds of time periods, called 
periods of stability and of adaptation. 

Stability is any time period during the run-time of an AS, during which one of 
the following conditions holds: 

• Values of Change Scope are not changing; 

• Values of Change Scope variables are changing, but these variables are not Mon¬ 
itored Variables; 

• Values of Change Scope variables are changing, and some or all of them are 
Monitored Variables. The changes result in new values for Criteria and/or Param¬ 
eters. However, these changes are within some ranges that we judged tolerable at 
design-time. 
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As the values of Monitored Variables influence values of Criteria, they also in¬ 
fluence the Problem Instance that the AS needs to be solving. As the values of 
Monitored Variables change, so does the Problem Instance to solve. At some time at 
the run-time, the AS should run according to the Optimal Specification that solves 
the Problem Instance applying at that time period. 

Adaptation is the time period during the run-time of an AS, when the AS is 
running according to the Specification which is not the Optimal Specification for 
the Problem Instance that the AS should solve at that time. 

To clarify this, suppose that Ti denotes a time period, during which the Moni¬ 
tored Variables result in Criteria values which give one Problem Instance A, and the 
Optimal Specification X solves A. During Ti, the AS runs according to X. 

Let 72 be a time period which immediately follows Ti. T 2 starts with values of 
Monitored Variables that give the Problem Instance B.lfB^A, and X does not solve 
B, it is necessary to find a new Specification Y which is the Optimal Specification 
forZl. 

Adaptation is the period during which the AS is searching for this new Spec¬ 
ification, and changes behavior from running according to X, to run according to 
Y. 


9.2.4 Relaxation 

If the AS were to react to every change in Criteria and Parameter values, stability 
periods would be shorter, and more resources would be invested in adaptation. 

Relaxation is used to allow the AS to run according to the same Specification in 
a broader range of conditions, and thereby potentially lengthen stability periods. We 
have three possible cases, depending on what changes for the AS, and relaxation 
can work in each case: 

• If only Criteria values change, then the goal is no longer to solve the Problem 
Instance, denote it A, that was relevant in the last stability period, but a new 
Problem Instance, denote it B. If the Specification X was the Solution to A, and it 
is not the Optimal Specification for B, then adaptation would involve finding the 
Specification Y, which is the Optimal Specification, and thereby the Solution to 
B. Adaptation can be avoided, if we allow X to be the Solution to both A and B. 

• If only Parameter values change, then the Problem Instance A to solve has not 
changed, but the AS is no longer running according to some Specification X 
from the last stability period, but according to a new Specification Y. There is 
no guarantee that Y is the Optimal Specification for A, but it can be the Optimal 
Specification for some other Problem Instance B. Adaptation would amount to 
finding a third Specification, which solves a Problem Instance C, whereby C is 
closer to A than B. To avoid adaptation in this case, relaxation would consist of 
allowing any one Specification from some set of Specifications to be the Solution 
to A. 

• If both Criteria and Parameter values are changing, then adaptation will involve 
finding the Optimal Specification to the new Problem Instance. To avoid adap- 
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tation, relaxation would need to be such that, the new Problem Instance is con¬ 
sidered sufficiently close to the one from the last stability period, and the new 
Specification as the Solution to the new Problem Instance. 

In the cases above, and using the terminology of ROPs, adaptation amounts to 
the act of recomputing the Solution to a ROP, when the Problem Instance changes. 
Relaxation, in contrast, is the act of not triggering the computation of a new Solu¬ 
tion to a new Problem Instance. At design-time, relaxation consists of changing the 
Criteria in the Problem Space, and changing Depend relations that link Parameter 
values to Criteria values. For example, suppose that we have formulated a ROP, and 
we want to relax it so as to allow more Specifications to be its Solution. 


9.3 Problem Statements 

RPAS is a double problem, one focused on design, the other on decision-making. 
They are defined as follows. 

Definition 22. Requirements Design Problem for Adaptive Systems (RDPAS): 
Given the information about the stakeholders’ expectations, the information about 
the environment of the system-to-be, and the predictions of changes to stakeholders’ 
expectations and the environment, define (i) the sequence of ROPs that the AS is 
expected to solve, and (ii) the Monitoring Scope needed to detect some or all of the 
predicted changes. 

Definition 23. Requirements Optimisation Problem for Adaptive Systems (ROPAS): 
Given a sequence of ROPs that the AS is expected to solve and the Monitoring 
Scope for the AS, find the set of Specifications and Evolution Requirements, such 
that, if the AS can run according to the Specifications, and while adapting satisfy 
the Evolution Requirements, then it will maximise the time that it runs according to 
the Optimal Specification in each stability period. 


10 ROP and Mathematical Optimisation 

Subclasses of the general ROP are made by restricting the properties of Criteria, 
Parameters, Depend relations, and the Decision Rule. 

Restrictions can be intended to narrow down the informal reading of the Criteria, 
Parameters, and Depend relations, and thereby the informal interpretation of an ROP 
as of a problem statement meaningful from the perspective of the ZJ view of RE. 

Eor example, the ZJ view distinguishes between requirements, domain knowl¬ 
edge, and specification. To capture this and define an ROP inspired by the ZJ view, 
the following would need to be done. All Criteria and Parameters need to be binary 
variables. The Criterion class should have two subclasses, requirement and domain 
knowledge. Specification should be the only subclass of the Parameter class. 
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Another kind of restrictions, independent from what one thinks RE is about, are 
on types of Criterion and Parameter variables, and the mathematical properties of 
Depend relations. They are interesting, because the general ROP is a subclass of the 
general mathematical optimisation problem, dehned as follows. 

Definition 24. Optimisation Problem ||^: A mathematical optimisation problem, 
or just an Optimisation Problem, has the following form: 


Minimise /o(.v) 

subject to fi{x) < bi, for i = 

where the vector .v = (xi,... ,x„) is called the optimisation variable of the prob¬ 
lem, the function /o(x) is called the objective function, the functions /i(x) < 
bi,...,fm{x) < b„f, are the constraint functions, and the constants bi,...,bm are 
the limits, or bounds, for the constraints. 

Definition 25. Optimal Solution : The Optimal Solution to an Optimisation Prob¬ 
lem is the vector x* if it has the smallest objective value among all vectors that 
satisfy the constraints: that is, for any x' with f\ (x') < hi,... ,/m(x') < we have 
/o(x') >/o(x*). 

ROP differs from the above in (i) having a different terminology, and (ii) equal¬ 
ity in constraints. These differences still make the ROP a subclass of the General 
Optimisation Problem above. We can therefore reuse resolution techniques from 
mathematical optimisation |013EO]|42l|60l[31] . For example: 

1. Depending on Criteria and Parameter variable types, we can have the following 
ROP subclasses: 

a. Binary ROP, where all Criteria and Parameter variables have binary value, 

b. Integer ROP, where all variables take an integer value. We can have this if 
we allow more than two levels of satisfaction of Criteria, and more than two 
configuration values for Parameters, 

c. Continuous ROP, if all Criteria and Parameters take real numbers as values, 

d. Mixed-integer ROP, if there are binary, integer, and continuous variables in 
the Decision Set. 

2. Depend relation properties give another classification dimension, where we can 
distinguish: 

a. Linear Depend relations, where every relation is a linear function, 

b. Nonlinear Depend relations, where every relation is an arbitrary nonlinear 
function, 

c. General Depend relations, where some relations are linear, others nonlinear. 
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11 ROP and Decision Analysis 

“Decision analysis is a logical procedure for the balancing of the factors that influ¬ 
ence a decision. The procedure incorporates uncertainties, values and preferences in 
a basic structure that models the decision.” 1^ 

The decision analysis procedure involves four steps llJ7lf38l . In step one, the aims 
are to specify the objectives to achieve by taking the decision, generate alternatives 
to choose from in order to achieve the objectives, and identify attributes used to 
measure the degree to which the objectives are achieved. Step two measures the 
uncertainty of the consequences of alternatives; the aim is to quantify uncertainty 
with a probability distribution of attribute values, with one probability distribution 
per alternative. Step three captures the relative desirability of value assignments 
to attributes. This gives a utility function, as a function over attributes. Step four 
ranks alternatives by their expected utility, by following the rule that the higher its 
expected utility, the more desirable the alternative. 

The problem in decision analysis can be formulated as an Optimisation Problem, 
as follows. 

Definition 26. Decision Analysis Optimisation Problem (DAOP) has the follow¬ 
ing form: 


i=n 

Maximise ^ {p{xj_i) * U{xj^i)) 

i=\ 

i—n 

subject to ^ p{xjj) — 1, for i = 
i=i 

where j denotes an alternative among m alternatives, i an attribute among n at¬ 
tributes, Xj,i the value of the attribute i when alternative j is chosen, p{xjf the 
probability of observing xjj for i when choosing alternative j, and U{xjj) the utility 
of observing xjj for i when choosing alternative J. 

Definition 27. Optimal Solution to DAOP is an alternative j* such that for any 

other alternative /, it is true that j) *U{xf j)) < 'fffflipixj*,i) *U{xj*j)). 

The relationship between ROP and DAOP is that there are subclasses of ROP 
which are also subclasses of DAOP. 

There are many such subclasses, and they depend on how ROP concepts are 
mapped to DAOP concepts. Here are the steps to follow, to make one such ROP 
subclass: 

1. Let every alternative j = I,...,min the DAOP be a point in the Solution Space. 

2. Let each attribute i= that is used to evaluate alternatives, be a Criterion 

in the Solution Space. 

3. Add one Criterion to the Solution Space, and call it utility. Its values are util¬ 
ity values, interpreted informally in the same way utility values are in decision 
analysis. Note that the Solution Space now has n + 1 dimensions. 
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4. Add Depend relations, which map values of all non-utility Criteria, or combi¬ 
nations of these Criteria, to values of the utility Criterion. This is the same as 
saying, using terms common to RE, that different levels of satisfaction of re¬ 
quirements and domain assumptions that these non-utility Criteria amount to, 
result in different levels of utility. It is necessary to add these Depend relations, 
because in decision analysis, utility is the aggregate measure of the attributes 
used to evaluate alternatives, and these relations will reflect this. If such Rela¬ 
tions were absent, it will look like the Decision Rule disregards all Criteria other 
than utility, or disregards all those Criteria whose values map to no utility value. 

5. Constraints L!=i = 1 for j = 1,... ,m from DAOP should be carried over 

as Depend relations to the ROR 

6. The Decision Rule of the ROP should be equal to the Depend relation that corre¬ 
sponds to the objective function in the DAOP. 

The resulting ROP subclass is a subclass of DAOP, in the sense that the only 
differences between DAOP and the ROP subclass are those of terminology and in 
the number of Depend relations, since it is necessary to add Depend relations that 
map non-utility Criteria values to the utility Criterion values. 


12 ROP and Expected Utility Theory 

“Expected utility models are concerned with choices among risky prospects whose 
outcomes may be either single or multidimensional. If we denote these various (say 
n) outcome vectors by x, and denote the n associated probabilities by p, such that 
the sum over / = 1 to / = n of p, equals 1, we then generally define an Expected 
Utility (EU) model as one which predicts or prescribes that people maximize the 
sum over i= 1 to i = n of F{pi) *U{xi). [...] Within this general EU model different 
variants exist depending on (1) how utility is measured, (2) what kind of probabil¬ 
ity transformations E(.) are allowed, and (3) how the outcomes x, are measured.” 
[Schoemaker: 1982] 

The DAOP introduced in the previous section is equivalent to the optimisation 
problem central to EU, so that the same remark as for DAOP applies: there is a 
subclass of SSOP which is also a subclass of the EU problem, and we can proceed 
to define that subclass in the way as for DAOP. 


13 Conclusions 

This paper argued that the Requirements Problem for Adaptive System is different 
from the DRP, and that it is not a subclass of the DRR It then proposed a general 
definition of the RPAS. Einally, the paper related RPAS to mathematical optimisa¬ 
tion in general, to decision analysis in management science, and to expected utility 
theory in economics. 
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